Nginx - Server names (Noms de serveur)
Table des matières
Wildcard names (Noms génériques)
Regular expressions names (Noms d'expressions régulières)
Miscellaneous names (Noms divers)
Internationalized names (Noms internationalisés)
Les noms de serveur sont définis à l'aide de la directive server_name et déterminent quel bloc de serveur est utilisé pour une demande donnée. Voir aussi « Comment nginx traite une demande ». Ils peuvent être définis à l'aide de noms exacts, de noms génériques ou d'expressions régulières:
server {
listen 80;
server_name example.org www.example.org;
...
}
server {
listen 80;
server_name *.example.org;
...
}
server {
listen 80;
server_name mail.*;
...
}
server {
listen 80;
server_name ~^(?<user>.+)\.example\.net$;
...
}
Lors de la recherche d'un serveur virtuel par nom, si le nom correspond à plus d'une des variantes spécifiées, par exemple, le nom générique et l'expression régulière correspondent, la première variante correspondante sera choisie, dans l'ordre de priorité suivant:
1.nom exact
2.nom générique le plus long commençant par un astérisque, par exemple " *.example.org"
3.nom générique le plus long se terminant par un astérisque, par exemple " mail.*"
4.première expression régulière correspondante (par ordre d'apparition dans un fichier de configuration)
Un nom générique peut contenir un astérisque uniquement au début ou à la fin du nom et uniquement sur une bordure de points. Les noms « www.*.example.org» et « w*.example.org» ne sont pas valides. Cependant, ces noms peuvent être spécifiés à l'aide d'expressions régulières, par exemple « ~^www\..+\.example\.org$» et « ~^w.*\.example\.org$». Un astérisque peut correspondre à plusieurs parties de nom. Le nom « *.example.org» correspond non seulement www.example.orgmais www.sub.example.orgaussi.
Un nom générique spécial sous la forme « .example.org» peut être utilisé pour correspondre à la fois au nom exact « example.org» et au nom générique « *.example.org».
Les expressions régulières utilisées par nginx sont compatibles avec celles utilisées par le langage de programmation Perl (PCRE). Pour utiliser une expression régulière, le nom du serveur doit commencer par le caractère tilde:
server_name ~^www\d+\.example\.net$;
sinon, il sera traité comme un nom exact, ou si l'expression contient un astérisque, comme un nom générique (et probablement comme un nom non valide). N'oubliez pas de placer les ancres « ^» et « $». Ils ne sont pas requis syntaxiquement, mais logiquement. Notez également que les points de nom de domaine doivent être échappés avec une barre oblique inverse. Une expression régulière contenant les caractères « {» et « }» doit être entre guillemets:
server_name "~^(?<name>\w\d{1,3}+)\.example\.net$";
sinon nginx ne démarrera pas et affichera le message d'erreur:
la directive "nom_serveur" ne se termine pas par ";" dans ...
Une capture d'expression régulière nommée peut être utilisée plus tard comme variable:
server {
server_name ~^(www\.)?(?<domain>.+)$;
location / {
root /sites/$domain;
}
}
La bibliothèque PCRE prend en charge les captures nommées en utilisant la syntaxe suivante:
?<name> | Syntaxe compatible Perl 5.10, prise en charge depuis PCRE-7.0 |
?'name' | Syntaxe compatible Perl 5.10, prise en charge depuis PCRE-7.0 |
?P<name> | Syntaxe compatible Python, prise en charge depuis PCRE-4.0 |
Si nginx ne démarre pas et affiche le message d'erreur:
pcre_compile() failed: unrecognized character after (?< in ...
cela signifie que la bibliothèque PCRE est ancienne et que la syntaxe « » doit être essayée à la place. Les captures peuvent également être utilisées sous forme numérique: ?P<name>
server {
server_name ~^(www\.)?(.+)$;
location / {
root /sites/$2;
}
}
Cependant, une telle utilisation doit être limitée à des cas simples (comme ci-dessus), car les références numériques peuvent facilement être écrasées.
Certains noms de serveurs sont traités spécialement.
S'il est nécessaire de traiter des demandes sans le champ d'en-tête «Host» dans un bloc serveur qui n'est pas la valeur par défaut, un nom vide doit être spécifié:
server {
listen 80;
server_name example.org www.example.org "";
...
}
Si aucun server_name n'est défini dans un bloc de serveur , nginx utilise le nom vide comme nom de serveur.
Les versions nginx jusqu'à 0.8.48 utilisaient le nom d'hôte de la machine comme nom de serveur dans ce cas.
Si un nom de serveur est défini comme « $hostname» (0.9.4), le nom d'hôte de la machine est utilisé.
Si quelqu'un fait une demande en utilisant une adresse IP au lieu d'un nom de serveur, le champ d'en-tête de demande «Host» contiendra l'adresse IP et la demande peut être traitée en utilisant l'adresse IP comme nom de serveur:
server {
listen 80;
server_name example.org
www.example.org
""
192.168.1.1
;
...
}
Dans les exemples de serveurs fourre-tout, le nom étrange « _» peut être vu:
server {
listen 80 default_server;
server_name _;
return 444;
}
Il n'y a rien de spécial à propos de ce nom, c'est juste l'un d'une myriade de noms de domaine invalides qui ne se croisent jamais avec un vrai nom. D'autres noms non valides tels que « --» et « !@#» peuvent également être utilisés.
Les versions de nginx jusqu'à 0.6.25 supportaient le nom spécial « *» qui était interprété à tort comme un nom fourre-tout. Il n'a jamais fonctionné comme un nom de serveur fourre-tout ou générique. Au lieu de cela, il a fourni la fonctionnalité qui est désormais fournie par la directive server_name_in_redirect . Le nom spécial « *» est désormais obsolète et la directive server_name_in_redirect doit être utilisée. Notez qu'il n'y a aucun moyen de spécifier le nom fourre-tout ou le serveur par défaut à l'aide de la directive server_name . Il s'agit d'une propriété de la directive listen et non de la directive server_name . Voir aussi « How nginx processes a request (Comment nginx traite une demande)». Il est possible de définir des serveurs écoutant sur les ports *: 80 et *: 8080, et de diriger que l'un sera le serveur par défaut pour le port *: 8080, tandis que l'autre sera le serveur par défaut pour le port *: 80:
server {
listen 80;
listen 8080 default_server;
server_name example.net;
...
}
server {
listen 80 default_server;
listen 8080;
server_name example.org;
...
}
Les noms de domaine internationalisés ( IDNs ) doivent être spécifiés à l'aide d'une représentation ASCII (Punycode) dans la directive server_name :
server {
listen 80;
server_name xn--e1afmkfd.xn--80akhbyknj4f; # пример.испытание
...
}
Les noms exacts, les noms génériques commençant par un astérisque et les noms génériques se terminant par un astérisque sont stockés dans trois tables de hachage liées aux ports d'écoute. Les tailles des tables de hachage sont optimisées lors de la phase de configuration afin qu'un nom puisse être trouvé avec le moins d'erreurs de cache CPU. Les détails de la configuration des tables de hachage sont fournis dans un document séparé .
La table de hachage des noms exacts est recherchée en premier. Si aucun nom n'est trouvé, la table de hachage avec des noms génériques commençant par un astérisque est recherchée. Si le nom n'y est pas trouvé, la table de hachage avec des noms génériques se terminant par un astérisque est recherchée.
La recherche dans la table de hachage des noms génériques est plus lente que la recherche dans la table de hachage des noms exacts car les noms sont recherchés par parties de domaine. Notez que la forme générique spéciale « .example.org» est stockée dans une table de hachage de noms génériques et non dans une table de hachage de noms exacts.
Les expressions régulières sont testées séquentiellement et sont donc la méthode la plus lente et ne sont pas évolutives.
Pour ces raisons, il est préférable d'utiliser des noms exacts lorsque cela est possible. Par exemple, si les noms les plus fréquemment demandés d'un serveur sont example.orget www.example.org, il est plus efficace de les définir explicitement:
server {
listen 80;
server_name example.org www.example.org *.example.org;
...
}
que d'utiliser le formulaire simplifié:
server {
listen 80;
server_name .example.org;
...
}
Si un grand nombre de noms de serveur est défini ou si des noms de serveur inhabituellement longs sont définis, il peut s'avérer nécessaire de régler les directives server_names_hash_max_size et server_names_hash_bucket_size au niveau http . La valeur par défaut de la directive server_names_hash_bucket_size peut être égale à 32, ou 64, ou une autre valeur, selon la taille de la ligne de cache du processeur. Si la valeur par défaut est 32 et que le nom du serveur est défini comme « too.long.server.name.example.org», nginx ne démarrera pas et affichera le message d'erreur:
could not build the server_names_hash,
you should increase server_names_hash_bucket_size: 32
Dans ce cas, la valeur de directive doit être augmentée à la prochaine puissance de deux:
http {
server_names_hash_bucket_size 64;
...
Si un grand nombre de noms de serveurs est défini, un autre message d'erreur apparaîtra:
could not build the server_names_hash,
you should increase either server_names_hash_max_size: 512
or server_names_hash_bucket_size: 32
Dans un tel cas, essayez d'abord de définir server_names_hash_max_size sur un nombre proche du nombre de noms de serveurs. Seulement si cela n'aide pas, ou si l'heure de début de nginx est trop longue, essayez d'augmenter server_names_hash_bucket_size .
Si un serveur est le seul serveur pour un port d'écoute, alors nginx ne testera pas du tout les noms de serveur (et ne construira pas les tables de hachage pour le port d'écoute). Cependant, il y a une exception. Si un nom de serveur est une expression régulière avec des captures, alors nginx doit exécuter l'expression pour obtenir les captures.
•.Le nom de serveur spécial « $hostname» est pris en charge depuis la version 0.9.4.
•.Une valeur de nom de serveur par défaut est un nom vide «» depuis la 0.8.48.
•.Les captures de noms de serveurs d'expressions régulières nommées sont prises en charge depuis la version 0.8.25.
•.Les captures de noms de serveurs d'expressions régulières sont prises en charge depuis la 0.7.40.
•.Un nom de serveur vide «» est pris en charge depuis la 0.7.12.
•.Un nom de serveur générique ou une expression régulière est pris en charge pour être utilisé comme premier nom de serveur depuis la version 0.6.25.
•.Les noms de serveur d'expressions régulières sont pris en charge depuis la version 0.6.7.
•.Le formulaire Wildcard example.*est pris en charge depuis la version 0.6.0.
•.Le formulaire spécial .example.orgest pris en charge depuis la version 0.3.18.
•.Le formulaire Wildcard *.example.orgest pris en charge depuis la version 0.1.13.
écrit par Igor Sysoev traduction fr yann |